Axe overlay polish: left-align report and scroll highlighted elements clear of it#14680
Open
cwickham wants to merge 6 commits into
Open
Axe overlay polish: left-align report and scroll highlighted elements clear of it#14680cwickham wants to merge 6 commits into
cwickham wants to merge 6 commits into
Conversation
Collaborator
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
The overlay is appended into <main>, so page-level centering (e.g. the
jolla about template's 'div.quarto-about-jolla main { text-align:
center }') centered the report text. The reveal report slide already
pins text-align: left; do the same in the base overlay rule.
Hovering a selector in the report scrolled the target element to the
viewport center with scrollIntoView({block: 'center'}), where the fixed
bottom-right overlay (max-height: 50vh) could cover it. Compute the
scroll target with a new exported pure helper, overlayAwareScrollTop,
that centers the element in the viewport band above the overlay instead;
elements with no horizontal overlap (or when the overlay leaves no
usable band) keep the default centering. Only the plain-HTML fixed
overlay takes this path: reveal navigates slides and the dashboard
offcanvas is a static full-height panel that vertical scrolling can't
dodge.
The overlay itself never moves or fades, so the mouse stays inside it
during the scroll and no mouseleave -> unhighlight flicker can fire.
Unit tests cover the helper's geometry; a Playwright test hovers a
violation near the bottom of a long page (with enough violations to
inflate the report to its max-height, without which default centering
already clears the overlay and the test has no teeth) and asserts the
highlighted element settles fully above the overlay. The spec also
gains a text-align: left assertion on the HTML overlay for the
left-alignment fix.
…board The overlay scrolls once the report exceeds max-height: 50vh, but wasn't keyboard-focusable — failing axe's own scrollable-region-focusable rule (serious, WCAG 2.1.1) when scanned directly. Add tabindex=0 plus role/aria-label in createReportOverlay only: the reveal slide and dashboard offcanvas variants don't scroll the report element itself, so they don't get the extra tab stop. Verified by running the pinned axe-core build against the rendered overlay on the long-report test page: scrollable-region-focusable before the change, no violations after. Note the violation-target spans remain mouse-only; full keyboard operability of the report is tracked separately.
The overlay is injected after the page scan, so it never audits itself and nothing else guards against new violations as the report UI grows. Scan it with the vendored axe-core build the page already loaded (window.axe), on the long-report page where the overlay is scrollable. Requires the vendored axe-core from #14677, which this branch is now stacked on. Verified the test fails with scrollable-region-focusable when the tabindex fix is removed.
cwickham
force-pushed
the
axe/overlay-polish
branch
from
27cc6b2 to
fa02ea5
Compare
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Note
Stacked on #14677 (vendored axe-core) and based against that branch; when it merges this PR retargets to
mainautomatically.Three quality-of-life fixes to the
axe: output: documentfixed overlay in HTML output.Left-align the report overlay. The overlay is appended into
<main>, so page-level centering leaks into the report text — e.g. an about page withabout: template: jollashipsdiv.quarto-about-jolla main { text-align: center }and centers the whole report. The reveal report slide already pinstext-align: left; the base overlay rule now does the same.Don't scroll highlighted elements underneath the overlay. Hovering a selector in the report scrolls the target element into view with
scrollIntoView({block: "center"}), but the overlay isposition: fixed; bottom: 3rem; right: 3rem; max-height: 50vh— a centered element (especially a full-width one) could land partly or wholly underneath it. The scroll target is now computed by a new exported pure helper,overlayAwareScrollTop, which centers the element in the viewport band above the overlay. Elements with no horizontal overlap keep the default centering, and only the plain-HTML fixed overlay takes this path: reveal navigates slides (the report is its own slide) and the dashboard offcanvas is a static full-height panel that vertical scrolling can't dodge. The overlay itself never moves or fades, so the mouse stays inside it during the scroll and nomouseleave→ unhighlight flicker can fire.Make the overlay itself pass its own scan. Running axe-core against the injected report (it never audits itself — it's added after the scan) flagged
scrollable-region-focusable(serious, WCAG 2.1.1): once the report exceedsmax-height: 50vhit scrolls, but wasn't keyboard-focusable. The overlay is now a focusable, labeled region (tabindex="0",role="region",aria-label), added only in the fixed-overlay path — the reveal slide and dashboard offcanvas don't scroll the report element itself, so they skip the extra tab stop. The violation-target spans remain mouse-only; full keyboard operability of the report is a separate issue.Tests: unit tests for the helper's geometry (
tests/unit/axe-overlay-scroll.test.ts), a Playwright test that hovers a violation near the bottom of a long page and asserts the highlighted element settles fully above the overlay (verified to fail against the old scrolling behavior), and assertions on the existing HTML overlay test fortext-align: leftand the focusable-region attributes. A self-scan regression test runs the vendored axe-core build (window.axe) against the injected overlay on the long-report page and asserts zero violations — the overlay is added after the page scan, so nothing else ever audits it (verified this test fails withscrollable-region-focusablewhen the fix is removed).Checklist
I have (if applicable):
AI-assisted PR